Advanced Internet protocol (IP) packet routing capabilities have become available as an integral part of operating systems. Those capabilities allow flexible packet routing and network address and port translation. Network address translation (NAT) is the dynamic replacement of the source or destination network IP address of a packet as part of the routing process. For a description of network address translation, see P. Srisuresh and K. Egevang, “Traditional IP Network Address Translator (Traditional NAT),” RFC 3022, Internet Engineering Task Force (hereinafter “IETF”), January 2001, the contents of which are hereby incorporated by reference herein.
As illustrated in FIG. 1, a “network address translator” or “NAT box” or “NAT” 100 has been used as a tool for allowing plural hosts 110, 111, 112 in a stub network 130 to access the Internet (or another packet network) 150 using a single or only a few IP addresses. As commercially available for use in a home networking environment, such a box includes a processor for performing routing functions, ports such as 100 BaseT ports or 802.11 wireless connections for connecting hosts and other devices behind the box in a local area network, and a port for connecting to the outside network. In many available arrangements, the processor is configurable by one of the networked hosts. Such an arrangement hides the actual configuration of the network behind the NAT box from probes received on the open Internet, while conserving the number of global Internet addresses actually used.
NATs pose many challenges to protocols and to the Internet architecture. Relevant to the present invention, NATs pose a barrier to counting the number of hosts on the Internet. Until now, there has been no way to count how many distinct hosts are hidden behind NATs. Such counting is useful in certain situations to be able to detect the existence of NAT boxes, and to tell how many computers are behind one.
A NAT box will use a very small number of IP addresses—perhaps just one—but can act as a relay for many different hosts behind it. Some cable companies restrict such usage as part of their “terms of service.” There are reports in the press of people reselling broadband services, especially via 802.11 wireless networks, to neighbors, in violation of tariffs and usage policies. Generally, such resale is via NAT boxes. Network access providers therefore have a need to count the number of hosts that are utilizing a single account.
The present invention takes advantage of an identifier such as the “ID” field located in headers of packets leaving the NAT box. IP protocol defines an IP header containing protocol information. The header is located at the beginning of an IP packet. For a more complete definition of the IP header and its fields, see J. Postel, “Internet Protocol,” RFC 791, IETF, September 1981, the contents of which are hereby incorporated by reference herein. The IP header contains fields ranging in length from 3 to 32 bits that are assigned to carry information such as the protocol and protocol version of the header, the total length of the packet, a fragment offset for the case where the packet has been fragmented, a time to live, a header checksum, the source and destination addresses, etc.
The “ID” field in an IP header (or “IPid”) is an identifying value assigned by the sender to aid in assembling the fragments of a packet. The field is used by a receiving host to distinguish the fragments of one datagram from those of another. The originating protocol module is required under the IP protocol to set the IPid to a value that is unique for that source/destination pair and protocol for the time the datagram will be active in the system.
To assemble the fragments of an Internet datagram, an Internet protocol module at a destination host combines Internet datagrams that all have the same value for the four fields: IPid, source, destination, and protocol. If there is no fragmentation, there is no need for the IPid field. On the other hand, fragmentation can, in theory, happen anywhere. The IPid field must therefore be unique in all “live” packets that have the same protocol number and source and destination IP addresses.